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^ (54) Title: SERVER-BASED MULTI-STANDARD HOME NETWORK BRIDGING 
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(57) Abstract: A bridge in a home network couples first and second clusters of devices.- The clusters have different software ar- 
chitectures. The bridge is connected to a server on the Internet. This server offers a lookup service for some set of standards, and 
allows a bridge to locate and download the appropriate translation modules for allowing a device in the first cluster to interact with 
the second cluster. 
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Server-based multi-standard home network bridging 



This application is a Continuation-in-Part of U,S. serial no. 09/340^72 
(attomey docket PHA 23,634) filed 6/25/99 for Yevgeniy Eugene Shteyn for BRIDGING 
MULTIPLE HOME NETWORK SOFTWARE ^ 

The invention relates to the bridging of multiple networks based on difG^ent 
5 software architectures. The invention relates in particular to home networking. 

It seems to be unlikely that there will ever be a single universally £q)plicable 
networking standard for each device in the home. Multiple standards for software 
architectures coexist and new ones will raaerge. New standard interfaces will be developed 
for new types of devices that are specifically targeted by those standards. Home ^plications 
10 are designed to make an intelligent use of all devices available in the home, but are not 

capable of dealing with each and every networking standard in use or becoming available in 
the future. Similarly, devices themselves will not be able to si5)port every existing home 
networking standard. For these reasons, bridges are needed between the different sub- 
networks or clusters, each respective one complying with a specific respective standard. A 
1 5 bridge serves to transparently represent a device, complying with a first standard in a network 
cluster of a first type, as a device complying with a second standard in a network cluster of a 
second type. The result is a single unified view of the home network available to software 
applications written for the first standard and as well those written for the second standard. 

Typically, a device on a network is controlled through a set of messages 
20 complying with the interface of the device. Interoperability between devices and software 
applications depends upon standard interfaces with a unique identification. Once an 
application knows the unique identification of the device, it knows the interface of the device 
and it can control the device by sending it messages. To the application it makes no 
difference whether it is sending standard messages directly to the device itself, or indirectly 
25 via a software component that translates these messages into a different set of message that 

(eventually) achieve the same desired effect or state change at the controlled device. Hence, a 
bridge between networks of multiple different standards can be considered a multi-standard 
device. That is, the bridge complies with each of these multiple standards, and hosts software 
components that translate device interfaces from a first to a second standard and vice versa. 
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For example, a bridge is used between a cluster of five devices complying with a standard A 
and three devices complying with a standard B, differeixt fi:oni A. The bridge hosts three 
traiislation modules for translating from A to B and five translation modules fo^ 
from B to A. Accordingly, a software application capable of interacting with only standard A 
5 devices can now control all eight devices. > 

U.S. serial no, 09/340,272 (attomey docket PHA 23,634) filed 6/25/99 for 
Yevgeniy Eugene Shteyn for BRIDGING MULTIPIJB HOME 

AROfflTECTURES, herein incorporated by reference, relates to the bridging of home 
networks of different software architectures. References to software representations of 

10 devices and services on a first one of the networks are automatically created. The reference 
are semanticaUy sufficient to enable autoinatic creation of at least partly fimctionally 
equivalent software representations for a second one of the networks so as to make the 
devices and services of the first network accessible fi:om the second network. This document 
also addresses the HAVi, Home API and Jini software architectures. 

15 In the following, the expression "translation niodule" includes the concept of 

"software representation", i.e., the representation in software of a physical device oir of a 
service on a network or a sub-set thereof so as to make the device or service accessible to the 
relevant messaging or controlling software. 

Preferably, a bridge performs the following fimctions: detection of the addition 

20 of a device in either of the bridged networks; identification of the type of the added device; 
locating the translation module for the identified device type if the device is likely to be of 
interest to the other network; and installing the translation module on the other network 
according to the procedure required by the standard used by that network. 

Successfiil standards will continue to define standard interfaces for newly 

25 developed devices in a domain considered relevant to those standards. This necessitates the 
development of accompanying translation modules that enable those new devices to be 
represented in networks based on different standards. As a consequence, a bridge is unable to 
contain all embedded translation modules for all possible, relevant devices that become 
available in the future. 

30 Accordingly, the inventors propose a solution wherein a bridge is connected to 

a server, e.g., on the Internet. This server offers a lookup service for some set of standards, 
and allows a bridge to locate and download the appropriate translation modules for use in the 
home network. 
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More specifically, the invention relates to a method of providing a service to a 
user of a home network. The mettiod comprises enabling a component of a first cluster in the 
network to interact with a second cluster of the home network. The first cluster has a first 
sofi^vare architecture, and the second cluster has a second software architectures different 
5 from the firat one. The first and second clusters are coupled through a bridge. The method 
comprises enabling a server external to the clusters, e.g., on the Internet, to receive a 
reference of a component having a first sofi^vare representation in the fijrst cluster. The bridge 
may provide this reference. The method further comprises enabling to provide to the bridge a 
translation module, associated with the refer^ce, for at least partially representing the 
1 0 component on the second cluster upon the module being installed on the bridge. 

A service provider thus can maintain and update a data base of translation 
modules for any nixiltiple standards being used in home networks. This partitioning and 
delegation of fimctionalities has many advantages as discussed below. 

The invention allows tihe bridge to be feirly "light-weight" or low-cost, as it 
1 5 does not need to have embedded translation modules for all possible devices of all standards 
that it could be connected to in the home. Storage and computation power is only needed for 
the devices that are actually bridged (i.e., storage is not needed for the ones that are 
potentially bridged), and only when they are bridged (e.g., "just-in-time"-bridging, i.e., at the 
time of connecting the new device to the network). 
20 Further, the invention renders the home network as a whole extensible and 

future-proof As new devices are invented and descriptions thereof become part of various 
standard specs, these descriptions are translated and uploaded to the bridge server by, e.g., 
the device manufacturer or a third party, to make them available for bridging in existing 
home networks. This process does not require any update mechanism of components in the 

25 home network itself 

A further benefit is that the bridge-server operator is able to obtain information 
about the configuration of the individual user's home network. This information can be used 
to the advance of both the user and the manufacturers and service providers. See, for 
example, U.S. Serial No. 09/160,490 (attorney docket PHA 23,500) filed 9/25/1998 for 

30 Adrian Tumer et al., for CUSTOMIZED UPGRADING OF INTERNET-ENABLED 

DEVICES BASED ON USER-PROFILE, incorporated herein by reference. This document 
relates to a server system that maintains a user profile of a particular end-user of consumer 
electronics network-enabled equipment and a data base of new technical features for this type 
of equipment, e.g., a home network. If there is a match between the user-profile and a new 
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technical feature, and the user indicates to receive information about updates or sales offers, 
the user gets notified via the network of the option to obtain the feature. Also see, e.g., U.S 
Serial No.09/1 89,535 (attorney docket PHA 23,527) filed 1 1/10/98 for Yevgeniy Shteyn for 
UPGRADING OF SYNERGEHC ASPECTS OF HOME NETWORKS, incorporated herein 
5 by reference. This document relates to a system with a server that has access to an inventory 
of devices and capabilities on a user's home network. The inventory is, for example, a look- 
up service as provided by HAVi, Jini and Home API architectures. The server has also access 
to a data base witb information of features for a network. The server determines if the 
synergy of the apparatus present on the user's network can. be enhanced based on the listing 
10 of the inventory and on the user's profile. If there are features that are relevant to the synergy, 
based on these criteria, the user gets notified. In this sense, U.S. serial ho. 09/189,535 relates 
to the concept of an "appUcation suggestor". 

A fiirther advantage of the invention resides in the fact that the server op^ator 
is enabled to measure market demands for particular devices to be bridged to a specific 
1 5 standard. The device manufecturer or another relevant third party can be notified of the 
emerging demand. When the new translation modules become available on the server, 
bridges that have sent requests for translation modules in the past with which the server coidd 
not comply, can now be notified of an upgrade. . 

Note that the bridge can be implemented as a software component on a device 
20 of a specific cluster on the home network in order to provide a bridge to anotiier cluster. For 
example, a HAVi set top box can have a software component for bridging the HAVi cluster 
to, e.g., a UPnP cluster on the network. Similarly, a PC that controls the UPnP cluster can 
have a software component that serves to bridge the UPnP cluster of the home network to the 
HAVi cluster. 

25 

The invention is explained in fiarfher detail, and by way of example, with 
reference to the accompanying drawing, wherein: 

Fig.l is a block diagram illustrating the principle of the bridging between two 
30 networks according to the invention; 

Fig.2 is a block diagram illustrating bridging HAVi to UPnP; and 
Fig.3 is a block diagram illustrating bridging UPnP to HAVi. 
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Throi^out the (toawnng, same reference numerals indicate sin^ 

corresponding features. 

As mentioned above an aspect of the invention relates to connectmg a brid^ 
to a server, e.g., on the Internet This server offers a lookup service for some set of standards, 
5 and allows a bridge to locate and download the ^ropriate translation modules in the home 
network that eventually enables a device on a sub-network of a first architecture to woric with 
devices on a sub-network of a second architecture. 

Fig.l is a diagram of a home network system 100 with a first cluster 102 of 
devices 104, 106 and 108 that comply witii a first software ardiitecture standard, heremr-afler 
10 called standard A. System 100 comprises a second cluster 110 of devices 112, 114 and 116 
that comply with a second software architecture standard, herein-after called standard B. 
Clusters 1 02 and 1 1 0 are interconnected through a bridge 1 1 8. In order to have a meaningful 
network interaction between cluster 102 of standard A on the one hand, and cluster 1 10 of 
standard B on the other hand, translation modules are mtroduced. These modules need to 
1 5 participate in both clusters 1 02 and 110. The modules typically need components local to the 
clusters, such as lower-level communication software, in order to be capable of this 
participating. Ratiier than having each traoslation module comprising its own communication 
software it is more efficient to provide tiiis software as an element of platform components 
120 of bridge 118. 

20 The process of the invention is now illustrated with an example wherein B- 

device 1 16 is going to be added to system 100. 

The first step comprises physically connecting B-device 1 16 to B-clustear 1 10, 

or "booting" B-device 116. 

In a next step, bridge 1 1 8 detects B-device 1 1 6 as a new addition, either 

25 because bridge 118 scans B-cluster 110 or its registry/directory/look-up service (not shown) 
periodically or because B-cluster 110 actively notifies bridge 1 18. Bridge 118 comprises a 
software Component 122, referred to as Installation Manager, that handles the installation of 
further software components needed to mtegrate B-device 1 16 uito system 100. An aspect 
hereof is discussed in, e.g., U.S. serial no. 09/340,272 (attorney docket PHA 23,634). In tiie 

30 latter document a software component, referred to as tiie Reference Factory, is capable of 
extractmg mformation firom any of the software representations of devices registered. This 
Reference Factory is capable of querying the inventory of services or of getting notified of a 
new software representation according to the metiiods of the relevant software architecture. 
Similarly, Installation Manager 122 receives or retrieves information descriptive of newly 
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added B-device 116. The descriptive informatioii is possibly reformatted before beii&g sent to 
a bridge server 124 via the Internet 126. In addition, bridge 118 preferably provides 
information about the local execution enviromnent of home network 1 00. This information is 
relevant to the software components that server 124 downloads onto bridge 118. The relevant 

5 irlfomiation regarding the enviromnent relates to the software architectures present, in this 
case the A-standard cluster 102 and the B-standard cluster 110. The information may also 
relate to the memory available, the type of operating system(s) being used, vh 
present, platform libraries, etc., on bridge 118. Based on this information server 124 is able to 
select the proper translation module or modules that fits or fit in best with the network 

10 enviromnentof system 100. 

Upon receipt of the descriptive and envux>nment information, server 124 uses 
a look-up service that needs to match the information, descriptive of B-device 116, with a 
translation module for representing B-device 1 16 in A-cluster 102. In general, server 124 has 
a plurality of look-up services available: one for each ordered pair (X, Y), v^^ierein X and Y 

15 axe the standards supported by server 124. In order to support bi-directional bridguig between 
a cluster of standard X and another cluster of standard Y, two look-up services are needed: 
(X,Y) and (Y,X). For support of bi-directional bridging between th^ 
different standards P, Q and R, six look-up services are needed: (P,Q); (Q J*); (P,R); (R,P); 
(Q,R); and (R,Q). Of course, server 124 may only support uni-directional bridging. 

20 Devices, such as devices 104-108 and 1 12-1 16, are often composite objects. 

For example, a TV set typically comprises Display, Amplifier and Tuner components. Server 
124 could first try to translate the composite object as a whole into anew composite device 
with an equivalent fimctionality. If that does not succeed server 124 could translate as much 
subsidiary components as possible on a one-to-one basis. This then would resxilt in a partial, 

25 but still usefiil, mapping. For example, if A-cluster 1 02 has not available a definition of a 

Timer, a B-type TV could still be bridged to A-cl\ister 1 02 as a monitor-like display/amplifier 
device. If a one-to-one relationship does not exist between particular subsidiary components 
in standard A and standard B, then a one-to-many or many-to-many moping could be used. 
For example, standard A might define volume control and equalizer effects as a single 

30 subsidiary component, whereas standard B distinguishes them as separate subsidiary 

components. In this case, a device in B-cluster 110 that contains just the volume control 
component, but not the equalizer component, camiot be bridged to A-cluster 102. On the 
other hand, a device in A-cluster 102 that contains a smgle amplifier component (volxune 
control as well as equalizer) can be bridged to network B by applying a one-to-two mapping 



wo 02/09350 




PCT/EPOl/08552 



7 

of fhe subsidiary components. In the most general case, a particular set of subsidiary 
components .in A-cluster 102 matches with another set of subsidiary components in B-cluster 
1 10 under a many-to-many mapping. 

Next, assume that a matching translation module 128 has been found it is 

5 downloaded to the bridge, installed on platform 120 and registered in accordance with the ^ 
protocol of standard A. This enables other applications and devices of A-clust^ 1 02 to 
discover ahd use device 116 through module 128. The installation and registering of module 
128 may be postponed until after it has been run on the execution environment of bridge 118.. 

The invention is explained below wifli an example illustrating the bridgmg of 

10 HAVi and Universal Plug and Play (UPnP) home networks with reference to Figs.2 and 3. 
The HAVi, Home API, and Jini standards for software architectures in the home networking 
field have been discussed to some detail in U.S. serial no. 09/340,272 (attorney docket PHA 

23,634) mentioned above and incorporated herein by reference. In HAVi, a DCM (Device 
Control Module) is a software element that represents a single device or ftmctionality on the 
1 5 HAVi network. The DCM exposes the HAVi defined APIs for that device. DCMs are 
dynamic in nature: if a device is inserted or removed from the network, a DCM for that 
device needs to be installed or removed, respectively, in the network. DCMs are central to the 
HAVi concept and the source of flexibility in accommodating new devices and features into 
the HAVi network. 

20 Universal Plug and Play (UPnP) is an open network architecture that is 

designed to enable simple, ad hoc communication among distributed devices and software 
applications firom multiple vendors. UPnP leverages Internet technology and extends it for 
use in non-supervised home networks. UPnP aims at controlling home appliances, including 
home automation, audio/video, printers, smart phones, etc. UPnP distinguishes between 

25 Control Points (CPs) and controlled devices (CDs). CPs comprise, e.g., browsers running on 
PCs, wireless pads, etc., that enable a user to access the fimctionaHty provided by controlled 
devices. 

UPnP defines protocols for discovery and control of devices by CPs. UPnP 
does not define a streaming mechanism for use by AudioA^ideo devices. Some of the 
30 discovery and control protocols are part of the UPnP specification while others are separately 
standardized by the IETF (Internet Engineering Taks Force). Interaction between CPs and 
devices is based on the Internet protocol (IP). However, UPnP allows non-IP devices to be 
proxied by a software component ruiming on IP-compliant devices. Such a component, called 
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Controlled Device (CD) proxy, is responsible for translation and forwarding of UPnP 
interactions to the proxied device: 

' A UPnP device has a hierarchy of sub-devices with at the lowest level 
services. Both devices and services have standardized types. A device type determines the 
5 sub-^devices or services that it is allowed to contain. A service type defines the actions and 
state variables that a' service is allowed to contain. State variables model the state of the 
device, actions can be invoked by a CP in order to diange that state. The description of tiie 
state variables and the action is called the SCP (Service Control Protocol). A UPnP device 
provides a description of itself in the form of an XML document. This document contains, 
1 0 among other things, the service types that it siqpports. Optionally, a device may have a 
presentation server for direct UI control by a CP. 

UPnP relies on AutoIP, which provides a means for ah IP device to get a 
unique address in the absence of a DHCP server. UPnP defines a discovery protocol, based 
on UPP multicast, called SSDP (Sunple Service Discovery Protocol). SSDP is based on 
15 devices periodically multicasting announcements of the services that they provide. An 

announcement contains a URL to which service actions are to be sent: the control server. In 
addition to that, CPs may query the UPnP network for particular device or services types or 
instances. 

UPnP relies on GENA (Generic Evait Notification Architecture) to define a 
20 state variable subscription and change notification mechanism based on TCP. 

After a CP has detected a service it wants to use (via SSDP), it controls Ihe 
service by sending SCP actions to the control server URL or querying for state variables. 
Actions are sent using HTTP POST messages. The body of these messages are defined by the 
SOAP (Simple Object Access Protocol) standard. SOAP defines a remote procedure call 
25 mechanism based on XML. 

The translation modules, or software representations, of H[AVi devices in 
UPnP are called Controlled Device (CD) proxies, while the software representations of UPnP 
devices in HAVi are called Device Control Modules (DCMs). 
HAVi to UPnP bridging 
30 Fig 2 is a block diagram of a home network system 200 illustrating the 

bridging from HAVi to UPnP, and shows in bold arrows the sequence of steps to bridge a 
HAVi device, here a digital camera, to UPnP. 

System 200 has a UPnP cluster formed by devices 202, 204, and 206. Device 
202 comprises a light, device 204 comprises an MP3 player, and device 206 comprises a 
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printer. System 200 has a HAVi network cluster formed by a TV 208, and a digital video 
recorder 210. The clusters are connected ttirougli bridge 118. 

In a step 212 a HAVi Camera 214 is physicaUy plugged into the HAVi's 1394 
network, thus makuoig Camera device 214 an active HAVi node. 
5 In a step 21 6 this addition is discovered by the HAVi Event Manager, residing 

on platform components group 21 8. The HAVi platform listens and reacts to the HAVi 
NewSoftwareElement event, or listens to a HAVi NetworkReset event to discover Camera 

214 as new device. 

In a step 220 the registration attributes of the DCM of Camera 214 and its 
10 FCM components are retrieved from the HAVi Registry on platform 218, and are encoded in 
some format understood by a bridge server 222, for example XML, and are sent to bridge 
server 222 usmg HTTP POST. Bridge 1 1 8 may use a HAVi Webproxy FCM to inq>lement 
this. 

In a step 224 a look-up component maps a HAVi device description, in the 
15 form of DCM/FCM registration attributes, to a UPnP CD proxy 226 for that device. Since 
UPnP CD proxies and HAVi DCMs are composite objects, the location process mi^t be 
implemented on the sub device (component) level, as described earUer. In HAVi a device 
(software representation is DCM) consists of a number oijuncttonal components (software . 
representation is FCM). To find out which FCMs are part of a DCM bridge 1 1 8 can use the 
20 DCM::GetFcmSeidList and FCM: :GetFcmType methods, or look at registry entries that have 
the same values for the QUID and nl field of the Targetld attribute. In UPnP, a device is a 
hierarchical strocture of sub devices with at the lowest level services. FCMs serve the same 
purpose as services. The mapping of HAVi device to UPnP CD proxy 226 might be from 
complete DCM to complete CD proxy, or partially from FCMs to proxy services. The 
25 moping of FCM to service might be 1-to-l, 1-to-many or many-to-many. 

In a step 228 downloaded CD proxy 226 is run on the execution enviromnent 
of bridge 118. This involves installing an http server for the unique URL of CD proxy 226. 

In a step 230 CD proxy 226 sends out periodic announcement messages, and 
responds to discover messages. This enables the other UPnP appUcations and devices to 
30 discover and use the HAVi Camera 214 through the CD proxy 226. 
T TPnP to HAVi bridging 

Fig.3 illustrates the steps to bridge a UPnP device, here printer 206 to HAVi 
cluster 208, 210, 214 in system 200. 
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In a step 302, UPnP Printer 206 is physically plugged into the UPnP network, 
and *powering-\q>' the UPnP device. 

• A next step 304 involves Usteiiing and reacting on the UPjqP device 
announcement message. 

5 In a step 306, the device description document of printer 206 is retrieved from 

the URL embodied in the announcement message, and tiie document is sent to bridge server 
222 usmg HTTP POST. 

A step 308 involves a look-up coinponent that maps a UPnP device 
description, in the form of a description document (in XML), to a HAVi DCM for that 

10 device, here printer 206. Since UPnP CD proxies and HAVi DCMs are composite objects, 
the location process might be implemented on the sub device (component) level, as described 
earlier. In HAVi a device (software representation is DCM) consists of a number of 
functional components (software representation is FCM). In UPnP, a device is a hierarchical 
structure of sub devices with, at the lowest level, services. Services that are part of a UPnP 

15 device can be fovmd in the device description document. FCMs serve the same purpose as 
services. The mapping of HAVi device to UPnP CD proxy might be from complete DCM to 
complete CD proxy, or partially from FCMs to services. The mapping of FCM to service 
might be 1 -to- 1, 1 -to-many or many-to-many. 

A step 310 involves running a downloaded Printer DCM 3 12 in the execution 

20 environment of bridge 118. This involves calling the DCM's Install method. 

A step 3 14 involves DCM 312 and its FCMs to create HAVi software 
elements, and using those to register with the HAVi registry component (which is part of 
platfomi components 218 available on bridge 118). 

In a step 316 the HAVi registry posts global NewSoftwareElement events for 

25 DCM 312 and all FCMs that are part of it. This enables the other HAVi applications and 
devices to discover and use UPnP Printer 206 through Printer DCM 3 12. 
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fcLAIMS: 



1. A method of providing a service to a user of a home network (100), v^erein: 

the method comprises enabling a component (1 16) of a first cluster (1 10) in 

the network to interact with a second cluster (102) of the home network; 
the first cluster has a first software architecture; 
5 » the second cluster has a second software architectures different from the first 

architecture; 

the first and second clusters are coupled through a bridge (118); 
the method comprises: 

- enabling a server (124) external to the clusters to receive a reference of a 
10 component having a first software representation in the first cluster; and 

- enabling to provide to the bridge a translation module (128), associated vsdth 
the reference, for at least partially represeaiting the component on the second cluster upon the 
module being installed on the bridge. 



15 2. The method of claim 1 wherein tiie server receives the reference team the 
bridge. 

3. The method of claim 1, wherein the bridge contacts the servCT via the Internet- 

20 4. The method of claun 1 , vrfhierein the first cluster comprises a HAVi cluster. 

5^ The method of claim 1, wherein the first cluster comprises aUPnP cluster. 

6. A data base comprising at least one translation module (128) for enabling a 



25 component (1 1 6) on a first home network cluster (1 1 0) of a first software architecture to 

interact with a second home network cluster (102) of a second software architecture i^on the 
module having been downloaded via the Internet on a bridge (1 1 8) that couples the first and 
second clusters. 
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